制造行业容器云平台设计与实施需要掌握的14个知识点
为了让大家了解容器云平台设计与实践过程，twt社区日前特别组织了线上的答疑活动，邀请某汽车主机厂容器云项目负责人作为答疑嘉宾。为了更好、更方便的让大家了解到活动的干货，更好地进行PaaS项目建设，现由活动嘉宾戴佳顺将问题和解答进行了总结，如有不妥之处，还请谅解。
Q1：容器云和虚拟化哪个效率高？
A：
容器的效率会高，这里的高指的是性能损耗方面。容器的image只是个rootfs，包括操作系统的整个运行环境，内核使用的还是宿主机的。同一宿主机下不管多少容器都得共享使用宿主机的内核，所以如果部分容器需要配置特殊的内核参数，做出的修改是全局的，这也是容器技术当下的一个特点，是优点也是缺点。传统的虚拟化技术没有这个问题。
早期做过个实验，同样性能的服务器虚拟化性能损失基本在20%左右，而容器化几乎没有性能损失。具体可以通过sysbench进行测试。容器可通过docker run -it --rm dotnetdr/sysbench:0.5 sysbench --test=cpu --cpu-max-prime=2000 run进行测试
Q2：容器云优点是什么？
A：
弹性、轻量、快速部署、自动扩容和自愈
Q3: 为什么docker热了？与哪些因素有关？
A：
cgroup和namespace是linux kernel的特征 ，过去使用起来很复杂，结果docker一个命令就可以搞定这些事情，从而使得用起来很方便。在虚拟化技术发展的过程中，比如一个物理机有10个虚拟机，每个虚拟机安装的操作系统会有大量的操作系统进程用于调度进程和管理硬件资源等，假设有20个操作系统进程，而实践经验中可能每个操作系统只部署一个web应用进程，从物理机角度看，这样上面的实际进程是 10个web进程/（10个虚拟机*20个操作系统进程）=1/20。
如果采用容器技术，那么在一个操作系统上面可以运行10个web进程，这样的实际进程是10个web进程/20个的操作进程=1/2。这样看来，更多的物理资源用来运行web进程，而多个进程可以共享一套操作系统的管理进程组，从而提升资源利用率。
Docker与传统容器比起来，有如下改善：
- 集装箱：黑盒运行模式，使得Build once, Run “anywhere”。（这点依赖于os kernel以及cpu：比如x86和arm，所以我打引号）但比起传统PaaS的环境差异性，是有极大改善的。
- 轻量和弹性：镜像层解构的创新，使得下层镜像“共享”方便传播和部署。
- 生态：CNCF
Q4: 为什么kubernetes会出现pod这个抽象？
A:
pod是基于容器更高层度的抽象，主要提供多容器的package运行。其核心实现了类似容器操作系统的抽象，使得可以在不侵入pod中容器的前提下对其进行底层控制，实现包括Sidecar、Ambassador或Adapter相关的模式。
从设计角度，一方面，如果每个容器都占用一个IP stack等资源，那么操作系统资源耗费会比较多。另一方面，多个容器之间可能存在一个逻辑上的相关管理，比如一个pod里面可以有一个web容器，一个mysql容器，web和mysql是互相关联的，如果放在一个pod中，二者可以共享一个IP stack。
具体参考https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/ 和 https://kubernetes.io/blog/2016/06/container-design-patterns/
Q5: 容器应用的监控方案如何设计？
A:
两个关键词：
1. sidecar
2. https://prometheus.io/
Q6: 应用向容器云迁移时有哪些技术障碍需要克服？有哪些风险需要预防？
A:
开发成熟度：应用耦合情况。我觉得微服务不是必须，但无状态服务是很大的前提。
人员成熟度：面对巨大的学习曲线是否有能力快速掌握
技术堆栈：传统和容器化的技术堆栈存在一定差异，如何共存？而不是简单建两套使得TCO剧增。
Q7:企业容器云的构建思路和步骤？
A:
首先需要确认做容器的初衷是什么，分析哪类业务需要容器化？
人员和组织定义：哪类人实施，开发团队准备好了么，运维团队准备好了么
技术堆栈选型：涉及哪类容器平台docker/k8s等，配套设施做哪些
实施方式定义：包括自建、外部partner等
Q8: 贵公司都是用的容器来部署微服务吗？ 能问下你们的容器架构是演化出来的，还是顶层设计出来的？
A：
看业务受众：如果是面向企业，由于业务链路长，建议从顶层往下解构，到level3之后再考虑服务化（而不是微服务化），这个和成熟度有关。
如果业务面向C或业务链路短，可以考虑通过下层快速迭代演进。
Q9: 贵企建设容器云平台，人员配置方面是怎样的？
A:
独立构建，涉及基础平台和上层服务。前者短期手工运维，但通过开发逐步自动化。后者通过开发实现。支撑人员和运营容器数量关系不大，但和上层开发服务的数量正相关。关键点：开发从上往下做。
Q10: 容器云平台的安全问题是如何保证的？
A:
需要考虑多个层次，主要包括：
容器主机：主机本身的安全设置、SELinux的启用、Cgroups和Namespaces使用等
容器镜像：基础镜像使用、基础镜像更新和漏洞扫描等
容器仓库：通过建立TLS仓库，并通过HTTPS绑定，这样Docker只能从授信的仓库获取镜像
容器构建和部署：与正常CI/CD类似，但需要规避业务应用使用特权容器运行的情况
容器平台：平台解决方案实现
Q11: 上容器之后会带来哪些方面的挑战呢？
A:
第一个：人。kubernetes学习曲线比起原生docker高很多，如何掌握学习脉络？
第二个：组织。传统稳态组织和敏态组织的演化和融汇。
第三个：文化。如何良性互动？
Q12: 企业容器云的性价比高吗？
A:
需要考虑下使用容器的初衷，究竟是业务的敏捷弹性需求触发呢还是交付复杂性需求初衷
同时需要注意：
资源利用率提升导致费用的节省、固定资产投资费用前后差异、人员学习成本及能力依赖差异、开源文化收益
Q13: openshift启动报错问题？openshift 启动老是报错 请专家看看是什么问题？
openshift 启动老是报错
A:
kubelet 默认的 cGroup 为 cgroupfs 而 docker 默认的 cGroup 为 systemd
需要在下列文件添加：
vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"
具体可参考https://github.com/kubernetes/kubernetes/issues/66747
Q14: 容器云的建设规划与方案设计需要遵循什么原则？
A:
满足不同形态业务用户需求。敏态：无状态容器化方案。稳态：有状态持久化方案。业务可用性。满足组织可用性需求。比如多活等。原则上整体可用性应不低于传统方案。当然由于容器的特性，需要架构和上层建筑保证。系统管理。满足原先组织监管相关需求。但需要平衡传统模式和新模式（类似devops）的差异，需要考虑在这过程中ITIL等流程如何更自动化智能化满足需求。
本次活动答疑嘉宾：戴佳顺，汽车行业8年工作经验，6年以上经销商领域应用架构设计和系统开发工作，具有非常强的架构解构和落地能力。目前正在负责PaaS平台和云服务平台建设工作，基于IT4IT理念为企业构建涵盖IaaS、PaaS和SaaS的一体化云平台。
本文还有王巧雷、bryan、hbhe0316等贡献。
相关阅读：
更多容器云主题内容请点击阅读原文
长按二维码关注公众号